Redirector Type

## I/O redirection

For many tasks, input and output can be defined in a fairly straightforward fashion. The exec task, used to execute an external process, stands as a very basic example. The executed process may accept input, produce output, or do either or both depending upon various circumstances. Output may be classified as "output" or as "error output." The `<redirector>` type provides a concrete means of redirecting input and output featuring the use of File Mappers to specify source (input) and destination (output/error) files. Since Apache Ant 1.6.2

The `<redirector>` element accepts the following attributes:

Attribute | Description | Required
output | Name of a file to which output should be written. If the error stream is not also redirected to a file or property, it will appear in this output. | No
error | The file to which the standard error of the command should be redirected. | No
logError | This attribute is used when you wish to see error output in Ant's log and you are redirecting output to a file/property. The error output will not be included in the output file/property. If you redirect error with the error or errorProperty attributes, this will have no effect. | No
append | Whether output and error files should be appended to rather than overwritten. Defaults to `false`. | No
createemptyfiles | Whether output and error files should be created even when empty. Defaults to `true`. | No
outputproperty | The name of a property in which the output of the command should be stored. Unless the error stream is redirected to a separate file or stream, this property will include the error output. | No
errorproperty | The name of a property in which the standard error of the command should be stored. | No
input | A file from which the executed command's standard input is taken. This attribute is mutually exclusive with the inputstring attribute. | No
inputstring | A string which serves as the input stream for the executed command. This attribute is mutually exclusive with the input attribute. | No
inputencoding | The input encoding. | No
outputencoding | The output encoding. | No
errorencoding | The error encoding. | No
alwayslog | Always send to the log in addition to any other destination. Since Ant 1.6.3. | No, default is `false`
loginputstring | Controls the display of inputstring's value in log messages. Set to `false` when sending sensitive data (e.g. passwords) to external processes. Since Ant 1.6.3. | No, default is `true`
binaryOutput | When set to true Ant will not try to split the output into lines - which it will usually do in order to separate error from normal output. This setting will not prevent binary output from getting corrupted if you also specify filter chains. Since Ant 1.9.4. | No, default is `false`

### Parameters specified as nested elements

#### inputmapper

A single File Mapper used to redirect process input. Multiple mapping results should concatenate all mapped files as input. Mapping will ordinarily be performed on a task-specified sourcefile; consult the documentation of the individual task for more details. A nested `<inputmapper>` is not compatible with either of the input or inputstring attributes.

#### outputmapper

A single File Mapper used to redirect process output. Mapping will ordinarily be performed on a task-specified sourcefile; consult the documentation of the individual task for more details. A nested `<outputmapper>` is not compatible with the output attribute.

#### errormapper

A single File Mapper used to redirect error output. Mapping will ordinarily be performed on a task-specified sourcefile; consult the documentation of the individual task for more details. A nested `<errormapper>` is not compatible with the error attribute.

#### inputfilterchain

A FilterChain can be applied to the process input.

#### outputfilterchain

A FilterChain can be applied to the process output.

#### errorfilterchain

A FilterChain can be applied to the error output.

### Usage

Tasks known to support I/O redirection:

- Exec
- Apply
- Java

The expected behavior of a `<redirector>` is to a great degree dependent on the supporting task. Any possible points of confusion should be noted at the task level.